Current Behavior

The daemon currently depends on client requests failing with a LOCK_FILES_CHANGED error to trigger a restart. This creates several issues:

• The daemon may stay running with stale dependencies if no requests come in
• The client must wait for a request to fail to trigger reconnection
• Special-case error handling is scattered across the client code

Expected Behavior

The daemon should proactively restart itself when lock files change, and the client should gracefully reconnect with exponential backoff for any server shutdown scenario.

Changes

Client-Side: Exponential Backoff Reconnection

• Add handleConnectionError() method that retries with exponential backoff (10ms → 5000ms, 30 attempts max)
• Preserve pending messages during reconnection and resend them once the new daemon is available
• Remove special-case handling for LOCK_FILES_CHANGED and NX_VERSION_CHANGED errors
• Remove retryMessageAfterNewDaemonStarts() method as it's no longer needed

Server-Side: Self-Restart on Lock File Changes

• Add startNewDaemonInBackground() to spawn a replacement daemon before shutdown
• Add handleServerProcessTerminationWithRestart() for restartable shutdown scenarios
• Detect lock file changes and proactively start a new daemon before responding with an error
• Keep version change handling simple (just exit, no restart)

Benefits

• More Resilient: Client recovers from any server shutdown, not just specific errors
• Cleaner Architecture: Server manages its own lifecycle, client doesn't need special cases
• No Request Dependency: Daemon doesn't wait for requests to detect changes
• Reduced Error Spam: Exponential backoff prevents connection error floods
• Future-Proof: Foundation for other restart scenarios (plugins, config changes)

Related Issue(s)

Part of daemon rework to make restarts more reliable and resilient.